Wowza on EC2とCloudFrontを使ってHLSライブ配信してみた

#Amazon CloudFront

#AWS

清水俊也

2017.06.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。先日以下のエントリでストリーミングサーバにWowzaを使ってライブ配信を行ってみました。

AWSのWowzaでライブ動画配信してみた

先日のエントリの構成は、ライブエンコーダから受けた映像をストリーミングサーバ（Wowza on EC2）から直接クライアントに配信するというものでした。この構成でもライブ動画配信はできており、例えば少数のクライアントのみを想定している場合などでしたら問題はありません。

ただある程度の規模になってくるとEC2側が動画配信の負荷（主にネットワーク帯域）に耐えられず、配信が不安定になるという問題が発生します。対策の一つとしてCDNをユーザの前段に入れることが考えられます。AWSならAmazon CloudFrontを導入することでこの構成が構築できますね。またCloudFrontを使用することでTCPコネクションをオフロードさせ配信サーバ側の負荷を下げるなどのメリットもあることから、小規模の配信でもCloudFrontを導入することが推奨されています。

ということで、本エントリではWowza on EC2の前段にCluodFrontを導入した構成でライブストリーミング配信を行ってみました。配信方式についてはHLS（HTTP Live Streaming） ^*1を使用しています。また実際にCloudFrontを導入した構成で複数台のクライアントに対してライブストリーミングを行い、この状態のCloudFrontのキャッシュヒット率、またオリジンであるEC2含めたネットワーク転送量を確認してみました。

構成図は下記のようになります。 wowza-cf-hls-001

また下記のWowza公式ドキュメントの手順を参考にしています。

WowzaのHTTPオリジン設定

まずはWowzaに対してHTTPオリジンの設定を行います。以前のエントリと同様にWowza Streaming Engineを起動し、Wowza Streaming Engine Managerへログインします。

AWSのWowzaでライブ動画配信してみた｜ Developers.IO

今回の検証に使用したWowza Streaming Engineのバージョンは4.6.0です。またインスタンスタイプは検証目的としてt2.smallを選択しました。

Wowza Streaming Engine Managerへログインしたら、画面上部のメニューからApplicationsをクリックし、アプリケーション追加画面に進みます。ここでLive HTTP Originを選択します。

アプリケーション名を入力して、[+Add]ボタンで進みます。今回は単純に「live-http-origin」というアプリケーション名としています。

詳細設定画面に進みます。今回はHLS配信を行うのでPlayback TypesはApple HLSのみを選択しました。その他設定内容を確認して、[Save]で設定を保存します。

設定保存後、「Saved! Your application is ready to use.」というメッセージが画面に表示され、設定完了です。Source(Live)画面からライブエンコーダ側に必要な設定を確認すると以下となっていました。これらはのちほどエンコーダ側の設定に使用しますので控えておきます。

Host - Server IP Address: EC2のIPアドレス
Host - Port: 1935
Application: live-http-origin
Stream Name: myStream

CloudFrontの設定

ストリーミングサーバ側の準備ができたら、続いていCloudFrontの設定（ディストリビューションの作成）を行います。Management Consoleから[Create Distribution]で進みます。配信方法の選択画面ではWebを選択します。（RTMPではないことに注意しましょう。）

続く画面でOrigin Domain Nameの欄にWowza Streaming Engineが稼働しているEC2インスタンスを指定します。なおCloudFrontのOriginの指定はドメイン名でしか行えない（IPアドレスでの指定ができない）ので、EC2のPublic DNSや別途設定した独自ドメイン名を指定します。その他の項目はデフォルト設定で構いません。例えばCache Behavior SettingsのOjbect Cachingの設定なども、デフォルトのUse Origin Cache Headersのままとしておきます。必要に応じてCNAMEsやログの設定などは行っておきましょう。

設定を終えたら[Create Distribution]ボタンでディストリビューションを作成します。

ライブ配信して確認してみる

CloudFrontの設定を行いディストリビューションのステータスがEnabledとなったら、実際にライブ配信を行いCloudFront経由で配信ができているか確認してみます。

以前のエントリと同様に今回もエンコーダにはiPhone上のWowza GoCoderアプリを使用しました。先ほどWowza Streaming Engine Managerでアプリケーションを作成した際に確認した情報をGoCoderに設定し、配信を開始します。

Wowza Streaming Engine Manager上ではHLS配信のアドレスは以下のように例示されています。（つまりオリジンであるEC2からの直接配信の場合のアドレスですね。）

http://[EC2インスタンスのIPアドレス]:1935/live-http-origin/myStream/playlist.m3u8

CloudFront経由の場合は[EC2インスタンスのIPアドレス]:1935の部分が変わるだけです。

http://[CloudFrontドメイン名]/live-http-origin/myStream/playlist.m3u8

またはCloudFrontのドメイン名に独自ドメインを設定して以下のようにもアクセスできます。

http://[独自ドメイン]/live-http-origin/myStream/playlist.m3u8

Wowza Streaming Engine Manager上で例示されているHLS配信アドレスは[EC2インスタンスのIPアドレス]:1935とポート番号を指定していますが、CloudFrontのディストリビューション設定でもこの1935番ポートは指定しませんでした。オリジンとなっているWowza Streaming Engineへは80番ポートでのアクセスでもHLS配信は行えるようです。

複数台からアクセスした場合の挙動を確認してみる

CloudFrontを経由しても問題なく動画が配信できています。続いて今度は、複数台の端末がライブ配信を視聴している状態で、CloudFrontのキャッシュヒット、オリジンの負荷などを確認してみます。

今回の配信の帯域は5Mbps、合計6台の端末から同時にライブ配信を視聴している状況で確認してみました。いずれの端末も同一のルーターにぶら下がった状態で、同じパブリックIPを持つ状態となります。

wowzacf-018-2

CloudFrontのキャッシュヒット率

CloudFrontのReports & Analytics画面のPopular Objectsの項目から、キャッシュヒット率を確認してみます。セグメントファイル（拡張子が.ts）についてはMissesが1、Hitsが概ね5以上でCloudFrontにキャッシュされたものが配信されていることがわかります。ファイルによってリクエスト数が異なるのは、Player側で再取得が発生した（端末側でのリロード等含む）、Player側で再生を停止していた、等が考えられます。プレイリストファイル（拡張子が.m3u8）についてはHits率が一桁台ですが、これはライブ配信の場合プレイリストファイルは適宜変更されるものなので正しい挙動と言えます。

CloudFrontとEC2のデータ転送量

続いてCloudFrontとEC2、それぞれのデータ転送量を確認してみます。まずCloudFrontについてはReport & Analytics画面のMonitoring and Alarmsの画面を確認します。

グラフは1分間隔となっています。動画のビットレートが5Mbpsですので、分間のByteに直すと、5 / 8 x 60 = 37.5MByte/分となります。これが6台ですので、37.5 x 6 = 225MByte/分。Variable Bitrateであることを考慮すれば、概ね想定通りのデータ転送量となっていますね。

対して、EC2側のデータ転送量を確認してみます。こちらはEC2のManagement ConsoleのCloudWatchモニタリング画面を確認してみました。

こちらは5分間隔です。動画のビットレート5Mbpsで分間だと37.5MByteなので、5分間だと37.5 x 5 = 187.5Byteとなります。CloudFrontのキャッシュヒット率で確認したとおり、動画本体となるセグメントファイルはオリジンであるEC2からは一度しか転送されていません。CloudWatchグラフはおおよそ150Mbyteから200Mbyteの間で推移していますので、概ね187.5MByteの値と一致しますね。

まとめ

Wowza on EC2の前段にCloudFrontを導入した構成でのライブストリーミング配信を行ってみました。またライブストリーミング配信時のCloudFront、ならびにオリジンであるEC2の状況を確認して、オリジンのEC2のネットワーク負荷（転送量）がCDNであるCloudFront側で吸収されていることが確認できました。

今回は動画再生クライアントである端末がすべて同じネットワーク内にある状況でしたので、オリジンへのアクセスは1度きり、それ以降のアクセスはすべてCloudFrontのキャッシュにヒットしているという状況になりました。検証段階ではなく実際に動画配信をWebサービス等として行う場合には、クライアントのネットワークロケーションもまちまちでCloudFront側のエッジサーバも複数台に分散され、キャッシュヒット率やキャッシュミスの数なども変わってくるかと思います。しかしネットワーク負荷としてはこの構成でCluodFront側で吸収できますので、インスタンスタイプ等適切に設定すればこちらの構成で大規模な動画配信サービスが構成できるのではないでしょうか。